1. Technical Field
The present invention generally relates to tools for developing software for international use and in particular to multi-language software development. Still more particularly, the present invention relates to an improved system and method for performing language translation in computer software.
2. Description of the Related Art
Software Internationalization
As computers have become more prevalent, it has become desirable for software developers to be able to market their products to those people who do not speak the native language of the software developers. In particular, it is desirable that software developed in the English language be available to those persons, both in the United States and in the rest of the world, that do not speak English. Accordingly, many software applications that are developed in English are later translated for use by non-English speakers.
The process of translating a software package into another (or more than one other) language is time-consuming and expensive. Each text message, menu, and button must be translated to allow the user to operate the program. The most direct way to do this is to search the entire program source code for every text string, i.e., every string of characters that would be displayed to the user, and translating each of these to the new language.
This approach has several problems. One problem is that the use of this method means that the software must be specifically translated and compiled for each intended language. This, of course, is an expensive process in itself, and means that any change in the source code requires each language version of the code to be edited and recompiled.
FIG. 2 shows an example of hardcoded labels in a Java application. In this Figure, window 200 shown with two graphical user interface (GUI) xe2x80x9cbuttonsxe2x80x9d 210 and 230. These buttons are created using a hard-coded Java xe2x80x9cJButtonxe2x80x9d call;
for example, code-line 220 calls JButton with the string argument xe2x80x9cOkxe2x80x9d, creating button 210 with text label xe2x80x9cOkxe2x80x9d.
Similarly. code-line 240 calls JButton with the string argument xe2x80x9cCancelxe2x80x9d, creating button 220 with text label xe2x80x9cCancelxe2x80x9d. To translate a software application which uses hard-coded strings as in FIG. 2, each line of the code must be parsed and each displayed string must be individually translated for each target language.
One solution to this problem is the use of separate localization files, in which the text strings that are to be displayed are stored separately from the executable code itself. As the software is executed, the text for every given display screen is simply read from the localization files, in whichever language is stored in the file. In this manner, the text in the localization file can be translated without disturbing the executable, and the executable can be changed or replaced without disturbing the translated text (except, of course, that if the text to be displayed changes, the corresponding entries in the localization files must also be changed). The localization files may be in any number of formats, including compiled message catalogs, Java resource bundles, HTML files, and many others.
The use of localization files provides an easy way to do multiple translations, but presents an additional problem in that the translation is performed on text isolated in a separate file, without any kind of context for the translator. Because this is the case, the translation will often contain errors which would not be present if the translator had been able to perform the translation according to the context in which the text appears.
However the translation is handled, each screen of the program in operation must then be proofread to ensure that the translated text is properly displayed and properly translates the text in the context of the display.
Therefore, it has become common practice to hire individuals with backgrounds in other languages to proofread each screen of the translated program to detect any display, grammar, or translation errors. This second phase is called Translation Verification Testing (TVT).
FIG. 3 shows a chart of a translation and testing cycle according to conventional methods. A typical Company A, located in Country A, builds the application intended for Country B (310). Next, Company A packages and ships the application to Company B, located in Country B (320). Company B will then execute the application to test for any translation or internationalization errors (330). Company B will then do TVT testing, note any translation errors, and make any necessary retranslations (340). Company B then ships the corrections back to company A, and the process repeats until no more errors are found.
According to this conventional process, each time an A error is corrected or a change made in translation in Country B, the product must be rebuilt and repackaged in Country A before it is retested. Because of this, the TVT process is necessarily an expensive and time-consuming process. It would therefore be desirable to provide a means to provide additional information to the translator, and contextual information in particular, so that the initial translation is as accurate as possible. By doing so, the cost and time required for TVT testing can be reduced or eliminated.
Java
Java is two things: a programming language and a platform. In one aspect, Java is a high-level programming language, and is unusual in that each Java program is both compiled and interpreted, to make it accessible to many platforms. Java is also a software-only platform that runs on top of other, hardware-based platforms. The Java platform has two components; the Java Virtual Machine (Java VM), amd the Java Application Programming Interface (Java API).
The Java VM is the base for the Java platform and is ported onto various hardware-based platforms. The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into libraries (packages) of related components.
JavaBeans brings component technology to the Java platform. JavaBeans API supports reuseable, platform-independent components. Using JavaBeans-compliant application builder tools, components can be combined into applets, applications, or composite components. JavaBean components are known as Beans.
It is therefore one object of the present invention to provide an improved tool for developing software for international use.
It is another object of the present invention to provide an improved tool for multi-language software development.
It is yet another object of the present invention to provide an improved system and method for performing language translation in computer software.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.
A more efficient translation process is made possible by providing a system, method, and program for providing language translators with contextual information for the text to be translated. The translator is presented with a graphical user interface in the base language, and can then interactively translate each text label on the screen. Because the translation is performed on the text in the proper context, by editing the text withing the target application itself, the time and expense of Translation Verification Testing is reduced or eliminated. The ability to edit the text within the application is achieved by adding an editor function to the software application itself. Each text label in the application is stored in a localization file as a Java wrapper class component, which combines contextual information, such as the associated resource bundle name and key, with the text label itself. When the is activated, the translator can edit the text directly, and the contextual information is used to store the translation for later use.